A/B (seamless) system updates

Description de A/B (seamless) system updates dans la documentation Android : https://source.android.com/docs/core/ota/ab

La méthode A/B (seamless) system updates a été introduite en 2016 dans la version 7 de Android : https://en.wikipedia.org/wiki/Android_Nougat#Platform

Chrome OS utilise aussi un système de A/B (seamless) system updates : https://www.chromium.org/chromium-os/chromiumos-design-docs/partition-resizing/#partition-layout

Journaux liées à cette note :

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "CoreOS de 2013 à 2018".

La première version d'Atomic Project paraît en 2014, avec rpm-ostree comme élément central, développé principalement par Colin Walters de Red Hat.

rpm-ostree utilise libostree comme fondation, composant qui lui confère "toute sa puissance".

OSTree composant central de Atomic Project

Colin Walters a créé libostree en 2011 pour les besoins de GNOME Continuous.

libostree est un outil qui s'inspire de Git, mais se spécialise dans la gestion d'arbres de fichiers complets de système d'exploitation.

Principales différences avec Git :

Aucune copie lors des checkouts : libostree repose sur des hardlinks, donc pas de working copy du fait de l'immutabilité des fichiers.
libostree préserve les contextes SELinux, les xattrs, les uid/gid, ainsi que des timestamps précis
libostree peut gérer les device nodes (/dev/zero, /dev/null…), les sockets (/run/systemd/notify...), et tous les types de fichiers d'un filesystem d'OS
Un mécanisme de déduplication
…

Avec OSTree, pas besoin de double partition

À la différence de CoreOS Container Linux qui utilisait le système de mise à jour A/B (seamless) system updates, Fedora Atomic Host (puis Fedora CoreOS) n'a pas besoin de deux partitions grâce à libostree.

Lors d'un upgrade, libostree réalise un "checkout" en utilisant la commande ostree-admin-deploy . Puis grub communique au kernel le paramètre ostree= qui détermine sur quel déploiement booter.

Voici les avantages de l'utilisation de libostree par rapport au système A/B (seamless) system updates :

libostree permet de conserver plusieurs déploiements, sans se limiter à 2
Grâce au système de déduplication, libostree consomme beaucoup moins d'espace disque
Grâce au téléchargement uniquement des deltas, les mises à jour sont très rapides

Néanmoins, alors que libostree offre techniquement la possibilité de créer autant de déploiements que souhaité, d'après mes tests, Fedora CoreOS semble actuellement limité à 2 déploiements seulement.
J'ai trouvé cette issue qui aborde ce sujet : support configuring host to retain more than two deployments.

rpm-ostree

Les utilisateurs d'Fedora Atomic Host n'interagissent pas directement avec libostree mais avec rpm-ostree.

rpm-ostree s'appuie sur les librairies libostree et libdnf pour installer des packages rpm et propose de nombreuses commandes d'administration de l'OS :

stephane@stephane-coreos:~$ rpm-ostree
Usage:
  rpm-ostree [OPTION…] COMMAND

Builtin Commands:
  apply-live             Apply pending deployment changes to booted deployment
  cancel                 Cancel an active transaction
  cleanup                Clear cached/pending data
  compose                Commands to compose a tree
  db                     Commands to query the RPM database
  deploy                 Deploy a specific commit
  finalize-deployment    Unset the finalization locking state of the staged deployment and reboot
  initramfs              Enable or disable local initramfs regeneration
  initramfs-etc          Add files to the initramfs
  install                Overlay additional packages
  kargs                  Query or modify kernel arguments
  override               Manage base package overrides
  rebase                 Switch to a different tree
  refresh-md             Generate rpm repo metadata
  reload                 Reload configuration
  reset                  Remove all mutations
  rollback               Revert to the previously booted tree
  search                 Search for packages
  status                 Get the version of the booted system
  uninstall              Remove overlayed additional packages
  upgrade                Perform a system upgrade
  usroverlay             Apply a transient overlayfs to /usr

Note suivante : "Fusion de CoreOS et Atomic Project en 2018.

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Système de mise à jour d'Android, Chrome OS, MacOS et MS Windows".

Première version de CoreOS Container Linux en 2013

La première version de CoreOS Container Linux sortie en 2013 utilisé la méthode A/B (seamless) system updates inspirée de manière transparente à Chrome OS :

Upgrading CoreOS is a bit different than the usual distros. Our update system is based on ChromeOS. The big difference is that we have two root partitions; lets call them root A and root B. Initially your system is booted into the root A partition and CoreOS begins talking to the update service to find out about new updates. If there is an update available it is downloaded and installed to root B.

source

D'après ce repository coreos/coreos-overlay, CoreOS Container Linux était basé sur les packages de Gentoo.

Première version d'Ignition en 2016

En avril 2016, l'équipe CoreOS a publié la première version de ignition, outil toujours utilisé en 2025 par Fedora CoreOS.

Ignition is a utility created to manipulate disks during the initramfs. This includes partitioning disks, formatting partitions, writing files (regular files, systemd units, etc.), and configuring users. On first boot, Ignition reads its configuration from a source of truth (remote URL, network metadata service, hypervisor bridge, etc.) and applies the configuration.

source

ignition est un système qui ressemble à cloud-init, mais qui est exécuté seulement une seule fois, lors du premier boot et est lancé en tout premier, avant même systemd.

Depuis 2019, les fichiers json ignition ne sont plus édités manuellement grâce à l'outil butane qui convertit des fichiers YAML butane en fichiers json ignition.

Voici la documentation de butane qui vous permet de voir les actions que peut effectuer ignition : https://coreos.github.io/butane/specs/.

À la différence de cloud-init, ignition fonctionne à un niveau plus bas. La spec Butane Fedora CoreOS v1.6.0 permet par exemple de configurer les partitions, le Raid, LUKS encryption…

Voici dans mon playground un exemple de son utilisation : atomic-os-playground/create-coreos-custom-iso.sh.

Note suivante : "2014-2018 approche alternative avec Atomic Project".

Cette note fait partie de la série de notes : "J'ai étudié et testé CoreOS et je suis tombé dans un rabbit hole 🙈".

Note précédente : "Ajout de packages dans des distributions atomiques".

Chrome OS et Android implémentent la stratégie de double partition A/B (seamless) system updates.
Cette technologie offre des mises à jour complètement transparentes en arrière-plan et un redémarrage immédiat.
En revanche, contrairement à la solution CoreOS (méthode détaillée dans cette note), cette méthode a pour inconvénient de consommer deux fois plus d'espace de stockage.

MacOS s'appuie sur les snapshots de son filesystem APFS (fonctionnalité qu'offre aussi btrfs). Cela garantit un retour en arrière rapide vers la version antérieure si des problèmes surviennent.
En revanche, l'upgrade se termine durant le reboot, pouvant prendre de 2 à 5 minutes, alors que le redémarrage reste instantané avec Chrome OS, Android, CoreOS ou Fedora Silverblue.

Comme d'habitude, je n'arrive pas à trouver des informations précises sur le fonctionnement interne de MS Windows 😔. D'après Claude Sonnet 4, le système de mise à jour de Windows 10 et Windows 11, baptisé Unified Update Platform (UUP), semble plutôt daté : pas d'A/B (seamless) system updates, absence d'atomicité, installation longue lors du reboot (10 à 30 minutes), possibilité d'échec en cours de processus, rollback complexe, aucun système de snapshot comparable à MacOS. J'ai du mal à croire ce bilan tellement catastrophique, ce qui m'amène à questionner sur l'exactitude des informations rapportées par Claude Sonnet 4.

D'après cette documentation particulièrement riche et mes recherches complémentaires, je pense que la stack libostree + composefs (avec zstd:chunked ) tel qu'implémenté dans Fedora CoreOS est probablement la technologie de mise à jour la plus avancée actuellement disponible.

Avant de présenter le fonctionnement du système de mise à jour de Fedora CoreOS en 2025, je vais retracer l'évolution technique de cette solution.

Note suivante : "CoreOS de 2013 à 2018".